Collaborative Design of Contribution Tracking Systems forDecentralized Organizations

public.icon

Quick sneak peek of the research!

https://gyazo.com/7c26a5a412c9e86d4a52754d736a5a08

ざっくりまとめ

自律分散型組織の中で「メンバーの貢献（contribution）をどのようにして追跡するのか」「それらをどう評価するのか」について仮説をまとめたペーパー

ここで課題になってくるのが、データの取得。

「何かしらの行動（貢献）が評価対象になる可能性があるよ」というのと、それを伝える（もしくはどこまで伝える？）みたいなのでハック対象にならないかが大事

ここがトレードオフな気がするけど、それをどうする？みたいな感じで続いていく

Abstract

We propose a set of opinionated defaults for kick-starting bottoms-up collaborative design of contribution record keeping, and discuss our work in progress aimed at swering empirical questions in this space.

以下、意訳

このポジションペーパーでは、研究者がどのようにして「貢献追跡システム（例えば、DAOメンバーとして参加する or OSSに貢献する）を」作ることができるのかという仮説を提案する。

特に、ログインしている最中の行動（ユーザー自身は受動的）」なのか、『フォーム等に記入してもらう（ユーザー自身が積極的に）』というトレードオフになりうる点について。

また、それらを利用するユーザーは"分析対象になっていること”を自己認識できるかどうか。つまり自分たちのcontributionがどのように分析されるか・分析される可能性があるかどうかを知っていることにも言及する。

私たちはこの「貢献追跡システム」に関する自説を提案し、この分野における実際に起こっている問題を解決することを目的として進めている私たちのプロジェクトを紹介する

At A Glance

Say we want to design a system for collaborative record keeping

Team building software projects want to log contributions

e.g., Alice added features, Bob fixed a broken test, Di wrote documentation...

A Group of friends wants to do collaborative filtering

Bob likes Movie X, Alice likes Movie Y

Key idea; each member will have an option about;

? how data is structured

? how data is processed

? how these opinions should be aggregated

「共同作業で記録を残すためのシステム」を設計したい

1. ソフトウェアプロジェクトを作るチームが、貢献したことを記録したい

例: Aliceは機能を追加した、Bobは壊れたテストを修正した、Diはドキュメントを書いた...

2. グループ同士で協調フィルタリングを行いたい

Bobは映画Xが好き、Aliceは映画Yが好き

重要なアイデア：各メンバーは以下のことについてオプションを持つことになる。

データがどのように構造化されるか

データがどのように処理されるか

これらの意見はどのように集約されるべきか

ユーザーが分析対象になっていることを自覚的にさせながら、自己申告ではなく無意識下の普段の行動を収集することで「特殊意志」（各個人の意志）を見出せるか

https://gyazo.com/e53278cabcc3c7963d25f6af80d99597

基本的には以下の4つの事象がある

「サーベイに対してユーザーが回答する」か、『ユーザーによって自発的に投稿されるデータ』の2つのデータからどちらよりなものを採用するか

反例: git

contributionは分析されるけど、ユーザーはその仕組みを知っている

「ログを生み出した本人がどのように使われるか知っている」or 『データを生み出した本人がどのように使われるかを知らない

反例: 従業員

従業員に、手間のかかる、謎めいたデータ・ラベリング作業を依頼する。

仮説：能動的なデータ作成を支援することで、利用意識を高める取り組みが、アクティブデータ作成への関心を高める。ほとんどの場合、この2つの次元には相関があります。

重要な仮説

常に自分が分析されている対象になることは常にいい（注目を集めない限りは）

積極的なデータ収集は特殊意志の可視化につながるが、アクティブとパッシブのトレードオフは 文脈に大きく依存する

これらのパラメータをコミュニティが独自に設定することができれば、これらのシステムはより効果的に機能するようになります。

https://gyazo.com/9ff8696cfceeac122ea1d3aff943b52e

多分だけど、つまりどういうことかをまとめてみる

現状取得しているデータを常に表示するのはもちろん、それがどのような意思決定に活用されたかが常に見れるようになっているのが理想的。そして、それらが起こった理由（導入される前の議論）も含めていつでも遡れるようになっている必要がある。

「そもそもどのデータを集めるべきか」と実装・仕様に関しては別々に議論する

proposal components

記録表

ユーザーが提供する 観測結果を提供する

現実の(一部)の有用な記述

直訳すると「スキーマ育成表」だけど、『どのようにしてデータ集めていきますか意見募集』

収集するデータについてどうあるべきかというユーザーからの意見

「もっと集めるべき or もう少し緩やかにするべき」などを決定する

table: Records Table

ユーザーは観察した結果（それは現実を一部切り取ったもの）を提供します

この関係は、「そもそもどんなデータ集める？」「どのようにして集めていくか」の順番での議論なのかな

table: Schema Cultivation Table

どのようなデータを集めていくかについて議論する

table: Application

付の記録で何か役に立ちたい 投稿記録

(集計、変換、フィルタリング。学習データとして利用する、など）

table: Preference Aggregation

その集めるデータをどのように既存のテーブルに追加していくか

例：スキーマの変更に伴う衝突を解決する方法

table: Preference Aggregation Cultivation

ユーザーからの意見そのもの

code:example.mmd

classDiagram

class レコードテーブル{

ユーザーは観測を提供します

}

class スキーマ育成テーブル {

レコードテーブルで収集されるデータの種類について、どのようにデータを集めていくべきかのかをユーザーから意見を募集する

}

class 統合設定 {

貢献度から考える どのように意見を集約するか を考えるために使う。

例：スキーマの変更に伴う衝突を解決する方法 スキーマの変更

}

class 選好集計理論 育成 {

ユーザーからの意見 プリファレンス アグリゲーションそのもの

}

class アプリケーション {

寄付の記録で何か役に立ちたい 投稿記録

(集計、変換、フィルタリング。学習データとして利用する、など）

}

class アプリケーション栽培表 {

どのようなアプリケーションを動かすべきか、ユーザーが意見を述べる (利用状況を把握することができる）

}

code:sa.mmd

graph LR;

code:exa.mmd

flowchart TD

center --> leftup & rightup <-- cnterbottum

leftdown --> center

cnterbottum --> center

rightdown --> center